search

backdrop / backdrop-issues

Issue tracker for Backdrop core.
145 stars 40 forks source link

Automate the updating of the tugboat DEV sandboxes (with each PR merged into core) #6475

Open klonos opened 7 months ago

klonos commented 7 months ago

This is NOT for the sandboxes for the stable releases, rather for the sandboxes for the latest 1.x in https://backdropcms.org/try-backdrop/dev

@stpaultim reported this in Zulip topic back in January, but I am guessing that this has been broken for a while. See, we have a documented task for each time we create a new minor or bug fix release, which has all the steps required for authorized people to be refreshing the demo Tugboat sandboxes used for https://backdropcms.org/demo ...that is a manual task though, which needs to happen each time that the demos are broken for some reason, as well as with each Backdrop core release. If we want the dev 1.x sandboxes to work and to be reflecting the latest changes each time one is spun up, we'd need to to automate this so that it happens each time a PR is merged into 1.x.

I thought that this was already automated on the Tugboat side of things: you point to a branch of a repo, and you're done. Things work automagically each time code is pushed/merged. Not sure if that got broken sometime in the past or was never working at all.

klonos commented 7 months ago

@quicksketch would that be something that the Tugboat folks could help us with? (and also, can I please have access to the project for these dev sandboxes so that I can help more next time?)

klonos commented 7 months ago

I do have access to the Tugboat dashboard for the regular core PRs as well as for the demo sandboxes, but not for this though, so I can't even take a look 🤷🏼

image

I'll bring this up during the dev meeting in a few hours.

indigoxela commented 7 months ago

Is your suggestion to update (means: rebase) each and every open PR every time core gets a merge?

Because the Tugboat sandboxes only refuse to build, if the branch is behind, when doing a push.

Uh-oh. First of all, this is a huge waste of resources. Secondly: with our limited amount of available GitHub Action runners this will never work (rebasing triggers automated tests). Third: that means, people have to - unexpectedly - update their local working copies, to be able to further work on a PR, otherwise they're stuck.

@klonos Unless I totally misunderstood your intention, this proposal sounds weird.

klonos commented 7 months ago

Yes @indigoxela, you misunderstood my suggestion. Perhaps I didn't do a good job explaining, so let me try again:

  1. We have the PR sandboxes - I am not suggesting that we change anything with them as part of this request here.
  2. We also have the demo sandboxes here: https://backdropcms.org/demo - this is not about them either.
  3. And then finally we have this sandbox here, which must not be as popular as the others: https://backdropcms.org/try-backdrop/dev

This issue here is about the 3rd type of sandboxes. I was saying that we already have a manual process to be updating the 2nd type of sandboxes when we make a new release of backdrop, but we don't have any task to be updating the 3rd type of sandboxes. It would not be practical to try to update the 3rd type of sandboxes manually, because we'd have to follow the manual process each time there is a merge into core. That's why I'm suggesting to automate that.

I hope that what I am suggesting is clear now.

indigoxela commented 7 months ago

This issue here is about the 3rd type of sandboxes.

Now I get it. :bulb: Many thanks for clarifying. :pray:

quicksketch commented 7 months ago

and also, can I please have access to the project for these dev sandboxes so that I can help more next time?

I don't have access to these sandboxes either. Was this something that @BWPanda set up? We might need set this up again, as I don't know if the corresponding Tugboat project even exists any more.