Infrastructure/loopabull-tasks
3
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

PR flags: adds support for running/pending state #1

Merged
ryanlerch merged 1 commit from fedora-ci/general/3 into master 2019-01-24 22:55:05 +00:00
Conversation 16 Commits 1 Files changed 4 +49 -18
mvadkert commented 2019-01-09 13:37:21 +00:00
Contributor
Copy link

This patch adds support for runinng state for Fedora CI.

It keeps only the recent flag around, so running transitions nicely
to complete/error state and vice versa (for reruns).

Resolves https://pagure.io/fedora-ci/general/issue/3

Signed-off-by: Miroslav Vadkerti mvadkert@redhat.com

This patch adds support for runinng state for Fedora CI. It keeps only the recent flag around, so running transitions nicely to complete/error state and vice versa (for reruns). Resolves https://pagure.io/fedora-ci/general/issue/3 Signed-off-by: Miroslav Vadkerti <mvadkert@redhat.com>
mvadkert commented 2019-01-09 13:38:07 +00:00
Author
Contributor
Copy link

@pingou @psss @bookwar kindly asking for review

I tested the script and it seems to work on our staging pagure instance we have internally. I was not able to test loop-a-bull ...

@pingou @psss @bookwar kindly asking for review I tested the script and it seems to work on our staging pagure instance we have internally. I was not able to test loop-a-bull ...
psss commented 2019-01-09 14:36:11 +00:00
First-time contributor
Copy link

I don't understand the implementation in detail but in general the proposed approach seems fine to me: Showing only one flag with either running or complete/error status is probably the best solution for now, until we get proper handling of pull requests versions/rebases.

I don't understand the implementation in detail but in general the proposed approach seems fine to me: Showing only one flag with either `running` or `complete/error` status is probably the best solution for now, until we get proper handling of pull requests versions/rebases.
mvadkert commented 2019-01-16 09:57:29 +00:00
Author
Contributor
Copy link

@kevev @puiterwijk @smooge @pingou hi, would anybody have time to review this pls? We would like to show this feature on DevConf CZ. Thanks very much.

@kevev @puiterwijk @smooge @pingou hi, would anybody have time to review this pls? We would like to show this feature on DevConf CZ. Thanks very much.
pingou commented 2019-01-16 10:23:26 +00:00
First-time contributor
Copy link

Let's add a default value to this variable so we're backward compatible

Let's add a default value to this variable so we're backward compatible
pingou commented 2019-01-16 10:24:18 +00:00
First-time contributor
Copy link

s/if/elif/

s/if/elif/
pingou commented 2019-01-16 10:25:30 +00:00
First-time contributor
Copy link

let's find a way to generate these, it shouldn't be a static and public string.

let's find a way to generate these, it shouldn't be a static and public string.
mvadkert commented 2019-01-21 10:54:39 +00:00
Author
Contributor
Copy link

rebased onto f4fd4c6ba2315be8cbfaa54cb63e0eaf976545f3

rebased onto f4fd4c6ba2315be8cbfaa54cb63e0eaf976545f3
mvadkert commented 2019-01-21 10:54:59 +00:00
Author
Contributor
Copy link

@pingou all issues addressed, politely asking for another round of review

@pingou all issues addressed, politely asking for another round of review
mvadkert commented 2019-01-21 10:56:18 +00:00
Author
Contributor
Copy link

rebased onto 3ccd19eca60777f6ec6c6ae7e4ab73a8b7ebf4e0

rebased onto 3ccd19eca60777f6ec6c6ae7e4ab73a8b7ebf4e0
pingou commented 2019-01-22 21:08:01 +00:00
First-time contributor
Copy link

We need to come up with a better way to generate the uid, this is still too weak :(

We need to come up with a better way to generate the uid, this is still too weak :(
mvadkert commented 2019-01-22 23:29:47 +00:00
Author
Contributor
Copy link

@pingou can you elaborate what is the problem, please? Is it that someone cannot fake easily the result or? Should I add more strings to the generation, so it is not just one value hashed? ... btw on downstream we just remove all old flags with "[citest]", is that something we do not want to do here?

The problem we were trying to solve with this was: https://pagure.io/fedora-ci/general/issue/1 (if we have just one result, no need to write which commit it relates to). Also with a rebase the reference to hash makes little sense.

@pingou can you elaborate what is the problem, please? Is it that someone cannot fake easily the result or? Should I add more strings to the generation, so it is not just one value hashed? ... btw on downstream we just remove all old flags with "[citest]", is that something we do not want to do here? The problem we were trying to solve with this was: https://pagure.io/fedora-ci/general/issue/1 (if we have just one result, no need to write which commit it relates to). Also with a rebase the reference to hash makes little sense.
mvadkert commented 2019-01-23 12:46:23 +00:00
Author
Contributor
Copy link

rebased onto 342bdeed29febe892d51084a057cc5b8183d367a

rebased onto 342bdeed29febe892d51084a057cc5b8183d367a
mvadkert commented 2019-01-24 09:37:54 +00:00
Author
Contributor
Copy link

rebased onto e803bad648

rebased onto e803bad6487dedd00f76118d7977022091c58297
mvadkert commented 2019-01-24 09:38:31 +00:00
Author
Contributor
Copy link

@pingou updated to use seed_flag_ci_pr variable for hash calculation. Please take a look. ty!

@pingou updated to use ```seed_flag_ci_pr``` variable for hash calculation. Please take a look. ty!
pingou commented 2019-01-24 22:54:51 +00:00
First-time contributor
Copy link

Looks fine to me :)

Looks fine to me :)
pingou commented 2019-01-24 22:55:05 +00:00
First-time contributor
Copy link

Pull-Request has been merged by pingou

Pull-Request has been merged by pingou
Sign in to join this conversation.
Reviewers
No reviewers
Labels
Clear labels   
Closed As
Duplicate
Closed with the reason of Duplicate

  
Closed As
Fixed
Closed with the reason of Fixed

  
Closed As
Insufficient Data
Closed with the reason of Insufficient Data

  
Closed As
Invalid
Closed with the reason of Invalid

  
blocked

Indicates the work cannot proceed. There is a dependency or an issue that is preventing the team from completing the task. This is a flag for the Scrum Master to help unblock the team.

  
Bug

The software is not behaving as expected. It could be an error, a crash, or an incorrect result. Bugs often need to be prioritized based on their severity and business impact

  
Chore

Tasks that are necessary but don't directly deliver new value to the end-user. These are internal tasks like updating a library, managing user accounts, or setting up a new service.

  
Feature

It's something that a user would be able to see or interact with, such as a new button, a new page, or an improved workflow.

  
in-progress

This label is for work that a developer is actively working on. This is usually what you'll see on the "In Progress" column of your project board.

  
points:1

A task that is simple, small, and has very little uncertainty. It should be easy enough for any team member to pick up and complete quickly, without a lot of discussion or research.

  
points:13

Any task that feels like it's a "13" or more is considered an Epic. These are too large and uncertain to be worked on in a single sprint.

  
points:2

This is a task that is slightly more complex or larger than a "1." It might involve two or three simple steps, but the outcome is still very clear and there's little uncertainty.

  
points:3

medium-sized task with some noticeable complexity. It might require a bit more thought or collaboration. The steps are well-defined, but it's not a trivial change.

  
points:5

a significant piece of work. It has more complexity and a higher degree of uncertainty than smaller tasks. It might require some research, a design discussion, or collaboration across multiple teams.

  
points:8

complex task with a lot of uncertainty. It's often the largest size that a team will consider for a single sprint. It likely requires a detailed breakdown and multiple team members to complete.

  
priority:high

This is for work that is critical and needs to be addressed in the next sprint. It's often for urgent bugs, important features, or a major piece of technical debt that is blocking other work.

  
priority:low

This is for work that is good to do but not urgent. It's a candidate for being worked on when there's extra time or when it rises in importance. It can stay in the backlog for a longer period.

  
priority:medium

This is for important work that should be done soon, but isn't as urgent as a high-priority item. It will likely be considered for the next 1-2 sprints.

  
ready

indicates that an issue has been fully refined, has a story point value, and is ready to be pulled into a sprint. It has all the information needed for a developer to start working on it immediately.

  
review

This indicates that the work is complete, but it is now in a review state. This could mean a peer code review, a QA check, or a review by the Product Owner.

  
Technical Debt

work that improves the codebase without adding new features. It's work that pays down the "debt" you've accumulated, such as refactoring a messy piece of code, improving test coverage.

No labels
Closed As
Duplicate
Closed As
Fixed
Closed As
Insufficient Data
Closed As
Invalid
blocked
Bug
Chore
Feature
in-progress
points:1
points:13
points:2
points:3
points:5
points:8
priority:high
priority:low
priority:medium
ready
review
Technical Debt
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
No assignees
3 participants
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference: Infrastructure/loopabull-tasks#1
No description provided.
Delete branch "fedora-ci/general/3"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?