fedora-qa / testdays-web

#81 Make staging deployment more flexible with a `staging` branch?
Opened by kparal. Modified

Open
Close Issue

Currently we deploy the develop branch to https://testdays.stg.fedoraproject.org . That's not super flexible, it makes testing a feature branch difficult, because it needs to be committed to develop first.

I think we could introduce a staging branch, which we would either point to the same commit as develop, or we could point it to any other commit, e.g. some feature branch. The staging instance would then be configured to use this staging branch, so any changes wouldn't need infra changes, just updating the branch tip in git.

The downside is that for the most common workflow, we'd need to commit to develop and also update staging branch to make it appear in staging. Is it worth it? What do you think?

Please note that we currently have no deployment automation, so openshift re-deployes still need to be triggered manually through openshift tooling. That could be another improvement (a different ticket), at least for staging.

Metadata Update from @kparal:
- Custom field story_points adjusted to 2

Not sure if it is even possible to do with our current tools but maybe another solution could be having CI watch pull requests and deploy new app test instance every time pull request gets created or updated. This test instance could have URL like https://.testdays.stg.fp.o for example.
The branch would just get pulled from pull request dynamically and this would eliminate need for managing extra staging branch.

That's an interesting idea. I don't know how difficult that would be. And it probably would need to use separate databases, because some PRs will do DB migrations.

This issue has been migrated to Fedora Forge:
https://forge.fedoraproject.org/quality/testdays-web/issues/81

Please continue any further discussion there.
Metadata
None

enhancement

None
None
Normal
2
Static archive. pagure.io was sunset in 2026; this is a read-only snapshot.
Red Hat Logo

Fedora is sponsored by Red Hat. Learn more about the relationship between Red Hat and Fedora »

© Red Hat, Inc. and others.